1. Field of the Invention
The invention relates to tire pressure monitoring sensors for vehicles and, in particular, to universal tire pressure monitoring sensors that are configurable to accommodate a variety of vehicles.
2. Description of Relevant Art
A tire-pressure monitoring system (TPMS) is an electronic system configured to monitor the air pressure inside a pneumatic tire on various types of vehicles. A TPMS reports in near real-time tire-pressure information to the vehicle's control system and to the driver. The TPMS discussed below are the so-called direct TPMS, which use sensors (interchangeably referred to as wheel units) mounted inside a tire for measuring the pressure of gases within the tire.
The sensor communicates with the vehicle's control module with the used of wireless signals, which are typically radio frequency (RF) signals. These signals contain the sensor-pressure information and, possibly, other data such as temperature, sensor identification number, or wheel location information. Moreover, an external programming unit may be used to communicate with the sensors (typically with the use of low frequency, LF, radio signals or physical contacts). The inbound communication may be used by a sensor installer to activate the sensor in order to receive the diagnostic information, or to modify the sensor to enable it to operate according to a particular TPM system specification.
The sensors may be installed by vehicle manufacturers as OEM (Original Equipment Manufacturer) products, or the sensors may be installed in installation facilities for replacement or refurbishment purposes as an after-market (AM) solution. The sensors may operate differently in different TPM systems, depending on a vehicle manufacturer, model, year of production, make, and TPMS manufacturer. The differences between TPM systems influence implementation of the sensor, for example: transitioning between different operation modes, triggering conditions for an internal program flow, learning algorithms, timing, wireless signal characteristics, communication protocol, data packet content, etc.
In order for a single sensor to cover most of the after-market (AM) TPM systems, these systems must be supported by the respective AM-TPMS sensor implementation(s). In order to accomplish this goal, one may either employ a multitude of sensor types, each implementing a single TPM system, or employ a universal sensor (which may be either used on all relevant existing vehicles directly, or which may be programmed/configured by an installer to support one or more TPM systems). Understandably, using a multitude of single-system sensor types is not desirable, as it requires the sensor installers to stock a multitude of various sensors. This, in turn, results in a high initial investment for the installer and the supply chain and makes the sensor selection time consuming. A universal sensor seems to be a much more economical solution.
U.S. Pat. No. 7,518,495 B2 discloses a method, systems, and tools for programming sensors with a software program that supports a single TPM system. Here, suitable program software for the sensor is selected from a database. This approach is very flexible because new program implementations may be added later to the database. As the full software has to be loaded to the sensor, the programming times are comparatively long, as a low speed communication interface is used. (Such interface is normally used for transmitting sensor specific data and triggers by the sensor installers.) Furthermore, the intense communication would reduce the capacity of the battery built into the sensor. Alternatively, a wired interface may be used. Such a wired interface requires additional hardware—like drivers and electrical contacts, for example—which make the sensor susceptible to ESD damage and corrosion at the electrical contact points. The handling of a wired interface is more complex, because a cable has to be connected to the sensor prior to the sensor's being programmed and disconnected after the sensor has been programmed.
U.S. Pat. No. 8,692,661 B2 discusses a universal sensor. Here, a plurality of selectable programs, configured to adapt the sensor to specific vehicles, are stored in the sensor during production. The required program is selected from the stored plurality by the sensor installer. Such approach facilitates a very fast programming of the sensor, as the correct program has to be only selected. The drawback of this solution, on the other hand, is that a large number of programs have to be stored in or on the sensor that further requires a large overhead of memory, thereby increasing the sensors costs. Alternatively, the memory-limited microcontroller of the sensor may only be pre-configured for a selection of vehicle models or protocols, which would again require keeping a large number of sensors on stock to provide AM coverage. A further disadvantage stems from the fact that, due to pre-stored on the sensor programs, no adaption to future requirements is possible. Instead, new sensors have to be developed.
US 2015/0202932 A1 discloses a sensor storing a basic version of a program in its memory. For configuration of the sensor in accord to the selected vehicle, the selected vehicle type program parameters are stored in memory. This allows for a comparatively fast programming, as only the parameters have to be transmitted to the sensor. An adaption to future requirements is only possible within the reach of the parameters, and basic new functions cannot be added.
EP 2821260 A1 discusses a method for setting a sensor by deleting the unnecessary encoding procedures. As initially a large number of encoding procedures has to be stored in memory, a comparatively large memory is required (or the memory limitation of commercial micro-controllers forces a number of sensors to be stocked which further increases the costs of the sensor). Finally, adaption of the proposed methodology to new TPM systems is not always possible, unless they fit into an existing TPM system. Otherwise, a new sensor has to be released.
Whenever a new TPM system appears on a market or an existing system is modified or if improvement possibilities or errors are uncovered within existing sensor software, the software must be updated. Some of the above-mentioned prior art relies on an external programming unit, used by the AM installer to perform field updates on a sensor by the means of wired or wireless communication. In US 2015/0202932 A1, for example, the range of field updates is limited by the underlying software system. This may require returning the sensors by the installer back to the producer for updates. In some cases such updates may simply not be possible due to hardware and software limitations, forcing the sensors to be withdrawn. The methodologies of U.S. Pat. No. 8,692,661 B2 and EP 2821260 A1, on the other hand, do not permit any level of software updates, and therefore sensor replacement is always required. This situation is disadvantageous and onerous not only for the installers but also for the entire supply chain as well as the sensor producers themselves. Under the circumstances, introduction of a new version number of the sensor for each software update may also be required, thereby affecting all parties involved in the sensor after market—with extra costs, greater handling complexity, time slips, human errors, and return rates.
The disclosure of U.S. Pat. No. 7,518,495 B2 enables full software field updates, but the required loading times may be long, which makes the discussed solution more prone to communication errors, thereby forcing the installer to repeat the process. The need to repeat the process is, reportedly, a major problem for the installers, as it induces extra costs and delays. Moreover, the intense data transfers may consume extended amount of battery power, thus limiting the sensor lifetime.
The disclosure of the published PCT application WO 2017202999 A1, fully included herein by reference, discusses a TPMS sensor having a bootloader configured to load vehicle specific configuration data.